Date: Fri, 26 Aug 94 04:30:20 PDT
From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
Errors-To: Ham-Digital-Errors@UCSD.Edu
Reply-To: Ham-Digital@UCSD.Edu
Precedence: Bulk
Subject: Ham-Digital Digest V94 #285
To: Ham-Digital


Ham-Digital Digest          Fri, 26 Aug 94       Volume 94 : Issue  285

Today's Topics:
                       HF -> internet gateways?
                        HF Packet (Mac vs PC)
                     HP100LX + Baycomm = Success?
                     jnos trace question (2 msgs)
                           jnos w/enet card
     mlhacker.zip - Zenith Minisport docs, hints, hacks & goodies
                    Packet Routing with JNOS 110f
                      What SB for Digital modes?

Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 25 Aug 1994 23:37:22 GMT
From: andyh@ucsd.edu
Subject: HF -> internet gateways?
To: ham-digital@ucsd.edu

i'm looking for gateways which can receive pactor, amtor, gtor or
rtty messages on HF and send them to an internet e-mail address.

i'd be most grateful if anyone who knows of such things could 
email me details. i'll compile and post the results.

thanks,

andy howard <andyh@burn.ucsd.edu>

------------------------------

Date: 25 Aug 1994 03:01:52 GMT
From: news.sprintlink.net!sun.cais.com!news.cais.com!news@uunet.uu.net
Subject: HF Packet (Mac vs PC)
To: ham-digital@ucsd.edu

Go ahead and get a Mac for this project,the software needed for what
you want to do exists and is sold by the major TNC manufacturers.
I heartdly recomend a Kam all mode TNC and Hostmaster for Mac from
Kantronics.If you cant get a source or number for the manufacturer,send
me some e-mail,I'll get it to you

------------------------------

Date: Thu, 25 Aug 1994 05:40:07 GMT
From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!usenet.ins.cwru.edu!news.csuohio.edu!sww@network.ucsd.edu
Subject: HP100LX + Baycomm = Success?
To: ham-digital@ucsd.edu

J. Sherwood Williams (jwill@cabell.vcu.edu) wrote:
: 
: Has anyone had any success using a Baycom type modem with the HP
: 100LX palmtop? Before I go out and mess with it, it would be good

The HP100LX works fine once the Baycom is powered by a 9 volt battery.
Works even better with a PacComm HandiPacket and MSYS.  With that it is a
full forwarding BBS with all the goodies (node, etc.).  In that way
I can forward to the home BBS when I have mail to deliver and the home
BBS can forward into me ... if I am there or not.  We also ran it with a
GTOR and Pactor port when running on a battery up in Algonquin Provintial
Park.  Worked great and saved all kinds of amp-hours as I didn't have to
use the other laptop.

I love it!

73,
Steve
     ag807@cleveland.freenet.edu
     no8m@no8m.#neoh.oh.usa.na

------------------------------

Date: 25 Aug 1994 13:46:06 GMT
From: noc.near.net!transfer.stratus.com!abersoch.sw.stratus.com!northup@uunet.uu.net
Subject: jnos trace question
To: ham-digital@ucsd.edu

	I have just started using jnos110f and have been having a problem
	with having a trace show up on the screen. I can make it go to a
	file. 	What am I missing ?

	Bill

--
--

    Bill Northup                   PHONE:	   (508) 460-2085
    Stratus Computer Inc.          INTERNET:	   northup@sw.stratus.com
    55 Fairbanks Boulevard	   Packet:         N1QPR@WA1PHY.#EMS.MA.USA.NA
    Marlboro, MA  01752            Amateur Radio:  N1QPR

------------------------------

Date: 25 Aug 1994 08:16:23 -0700
From: nntp.crl.com!crl4.crl.com!not-for-mail@decwrl.dec.com
Subject: jnos trace question
To: ham-digital@ucsd.edu

In article <33i7au$rr1@transfer.stratus.com>,
northup@abersoch.sw.stratus.com (Bill Northup) wrote:

>   I have just started using jnos110f and have been having a problem
> 	with having a trace show up on the screen. I can make it go to a
> 	file. 	What am I missing ?

An <F9> key.

After you have entered "Trace xxxx" <ENTER> (where "xxxx" is the
representation of the type of trace you wish), mash the <F9> key to
see the results.

You can tell if you mashed the key hard enough by observing the upper
left corner of the CRT (3rd line down).  It will change from "Command"
to "Trace". Mashing <F9> again will toggle back to Command Mode.

If you wish, you can use other F-keys to sequentially observe multiple
active sessions; <F1> being session 1, <F2> being session 2, etc.
Unfortunately, TRACE does not act like an independent session, and the
TRACE screen will "freeze" if you are watching another session.

Lou

------------------------Usual Disclaimers Apply-------------------------
Internet:  lgenco@crl.com                    Lou.Genco@LChance.sat.tx.us
Ham Radio Packet: N5SGL @ K3WGF.#SAT.TX.USA   tcp/ip: n5sgl@sat.ampr.org
------------------------------------------------------------------------

------------------------------

Date: 25 Aug 1994 01:08:48 GMT
From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!library.ucla.edu!csulb.edu!nic-nac.CSU.net!charnel.ecst.csuchico.edu!csusac!csus.edu!netcom.com!ix.netcom.com!netnews@network.ucsd.edu
Subject: jnos w/enet card
To: ham-digital@ucsd.edu

I am running JNOS 1.10f and have installed gvc ethernet cards in my
jnos pc and my other pc.  The cards check out fine between the machines
running the diagnostics.  The supplied driver comforms to FTP specs. I
have included the PACKET protocol in my config.h .   THe attach works
fine, but I cannot get jnos to recognize the packets I am sending to
it.  The trace on the port avails nothing.  Any ideas or suggestions
for debugging would greatly be appreciated, especially configuration
options for jnos I may not have set correctly.  Thanks.
73 de Bill Abernathy, kd5lu.

------------------------------

Date: Thu, 25 Aug 1994 02:42:38 GMT
From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!ulowell!simtel.coast.net!msdos-ann-request@network.ucsd.edu
Subject: mlhacker.zip - Zenith Minisport docs, hints, hacks & goodies
To: ham-digital@ucsd.edu

I have uploaded to the SimTel Software Repository (available by anonymous
ftp from the primary mirror site OAK.Oakland.Edu and its mirrors):

SimTel/msdos/packet/
mlhacker.zip    Zenith Minisport docs, hints, hacks & goodies

mlhacker.zip is a compendium of newsletters about the Zenith Minisport
laptop computer and its use as a packet radio host computer.  Zenith
offers only minimal and expensive support for this popular but
discontinued 8086 compatible notebook computer.  Newsletters contain
technical notes, construction projects, operating hints, resources,
architecture details and other related goodies.  The Minisport Laptop
Hacker series is the result of owning and repairing Minisports and
donations from others on Internet and the Amateur Radio packet networks.

Special requirements: None

Changes: Compendium includes Minisport Laptop Hacker #1 - #22.

FreeText.  Uploaded by the author.

Brian Mork
bmork@opus-ovh.spk.wa.us
ka9snf@ka7fvv.#ewa.wa.usa
6006-B Eaker, Fairchild, WA 99O11
V:509-244-3764  D:509-244-9260

------------------------------

Date: 25 Aug 1994 11:51:22 GMT
From: news.cerf.net!gopher.sdsc.edu!news.tc.cornell.edu!travelers.mail.cornell.edu!news.kei.com!yeshua.marcam.com!zip.eecs.umich.edu!newsxfer.itd.umich.edu!gatech!howland.reston@ihnp4.ucsd.edu
Subject: Packet Routing with JNOS 110f
To: ham-digital@ucsd.edu

I want to use JNOS as a packet switch between an AX25 serial link and an
ether net segment.

With the autoexec.nos listed below, I can ping machines on the 1.0.0/24
(ethernet) side of the net and I can ping machines on the 1.0.1/24
(AX.25) side of the net.  The problem I have is that if I try to ping
say 1.0.0.45 from 1.0.1.99, the packets dont go anywhere.  The default
route on my AX.25 machine is set to:

	route add default sl1 1.0.0.99

The way I figure it, 1.0.0.99 should see the ping for 1.0.0.45 from
1.0.1.99 and route ot from the AX.25 side out onto the ether net side
but this isn't hapening.  

Is there something I'm not doing right?

By the way, don't get upset about my IP numbers.  None of these nets are
connected to anything and just exist on an experimental test bed.

------------------------AUTOEXEC.NOS for 1.0.0.99------------
## ip setup
ip address 1.0.0.99
hostname dave.ards.dnd.ca.

## ax25 setup
ax25 mycall dave
ax25 bctext "ARDS testbed Daves Machine"

## attach interfaces
attach asy 0x3f8 4 ax25 sl1 1025 768 9600
ifconfig sl1 ipaddress 1.0.1.99
ifconfig sl1 descr "AX25 Connection to Laptop"

attach packet 60 lan1 100 1500
ifconfig lan1 ipaddress 1.0.0.99
ifconfig lan1 descr "Packet Connection to DLAEEM"

## Start Servers
start ax25
start ftp 
start telnet

## Routing
route add 1.0.1/24 sl1
route add 1.0.0/24 lan1

ip hport sl1 on
ip hport lan1 on
ax25 hport sl1 on

--

|------------------------------------------------------------|
| Captain Dave Mercer M.Eng., P.Eng.                         |
| Directorate of Land Armament and                           |
|   Electronics Engineering and                              |
|   Maintenance 2-3-3                                        |
| National Defence Headquarters                              |
| Ottawa, Ontario, Canada                                    |
| K1A 0K2                                                    |
|                                                            |
| Voice: (819) 997-9831                                      |
| Fax:   (819) 994-4246                                      |
| EMail: mercer@dgs.dnd.ca                                   |
| HAM: VE3XMJ                                                |
|------------------------------------------------------------|


-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3

mQCNAiw7jJkAAAEEALpAIvULlA/xvrzuR30NcLZE0HCHyGm5QR4ej8xM6k3AcH3T
Q3NkgV2FK5f8t/fBAhO1+ffa5K7F10B4hPqKkAASNlk1PIx9ty5oUgxAlZnfya4V
ScNIx0x2h2f3roRjiZLfNYM2zkm26sZhFQjVJxyNnluJq/xVb45/LyY+p9flAAUR
tCBEYXZpZCBNZXJjZXIgPG1lcmNlckBuY3MuZG5kLmNhPg==
=0azF
-----END PGP PUBLIC KEY BLOCK-----

------------------------------

Date: Wed, 24 Aug 94 20:27:08 PDT
From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!sdd.hp.com!svc.portal.com!portal!cup.portal.com!lgm@network.ucsd.edu
Subject: What SB for Digital modes?
To: ham-digital@ucsd.edu

all digital is on LSB on 20 meters

------------------------------

Date: Thu, 25 Aug 1994 16:34:28 GMT
From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!world!dts@network.ucsd.edu
To: ham-digital@ucsd.edu

References <1994Aug20.143652.9960@ke4zv.atl.ga.us>, <CuzyoI.8tt@world.std.com>, <33i45b$oao@acorn.acorn.co.uk>.com
Subject : Re: Looking for DXCluster software

In article <33i45b$oao@acorn.acorn.co.uk>,
Adrian Godwin <agodwin@acorn.co.uk> wrote:
>In article <CuzyoI.8tt@world.std.com>,
>Daniel T Senie <dts@world.std.com> wrote:
>>
>>How is the PacketCluster machine to know that the UI frame with a DX
>>spot just got stomped by another station starting to transmit a frame?
>>Packet radio does NOT run with Collision Detection in the way that
>>Ethernet does. You cannot tell, when transmitting, that your frame
>>has just gotten munched.
>>
>
>It's not that difficult : most broadcast protocols work on a NAK-only
>scheme - clients of the server respond only when they miss a packet,
>and the server than retransmits it.
>The method of detecting that missed packet varies, but a popular method
>is to number the transmitted packets and complain when a hole appears in
>the number sequence.

Adrian, thanks for your comments, and this is exactly what I was trying
to call out. There are certainly solutions such as numbered packets
which can be implemented. Essentially what you're doing then is to
create another protocol layered atop the broadcast mechanism. It's
not that different from the multicast implementations. I was primarily
pinting out that the "simple" solution that had been mentioned was
not sufficient.

>
>This has some difficulties for a DX-Cluster style service : as I understand
>it (I don't use DX Cluster) you expect transmissions at intervals, rather
>than a continuous stream. Thus, you wouldn't know you missed one until
>the next arrived - a second or an hour later. Regular empty packets, sent
>just to ensure everyone was up to date, might be sufficent to fix this,
>and there are more sophisticated schemes around to ensure this doesn't
>itself become a bandwidth hog. These require that the server keep track 
>of its clients rather than doing pure broadcast, but that's no worse than 
>having multiple VCs.

Exactly. The frequency of packets is an issue. It would be necessary to
send out null packets every 30 seconds or so to ensure all stations
received the broadcasts in a timely fashion. Even 30 seconds may be
too long... At some point you really clog the channel with null packets
placed there to ensure naks happen correctly when needed...

>
>However, I think you're correct to be concerned about low reliability of
>packet systems - on typical terrestrial packet, the success rate is very
>low. As a result, a protocol optimised for the assumption that most packets
>get through (and don't require ACKing) might turn out disastrously wrong -
>I think a successful broadcast scheme would require both a well-engineered
>high-reliability transmission scheme (good paths, no hidden terminals etc)
>and a protocol that gets no worse than multiple-VCs even in poor conditions.
>It might work pretty well with a full-duplex repeater and extremely well
>with a polled hub (where a small amount of reverse traffic can be effectively
>free by imposing no additional overhead).
>
>I don't know how closely satellite operation approaches this (do they split
>uplink and downlink packet frequencies ? ). I'd be interested to hear from 
>users of the Pacsat broadcast system and even more interested to hear from 
>anyone who has experimented with a terrestrial broadcast setup.

Dan
-- 
---------------------------------------------------------------
Daniel Senie                 Internet:     dts@world.std.com
Daniel Senie Consulting                    n1jeb@world.std.com
508-779-0439                 Compuserve:   74176,1347

------------------------------

Date: 25 Aug 1994 13:51:55 +0100
From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!EU.net!uknet!acorn!not-for-mail@network.ucsd.edu
To: ham-digital@ucsd.edu

References <3306v8$jbi@vixen.cso.uiuc.edu>, <1994Aug20.143652.9960@ke4zv.atl.ga.us>, <CuzyoI.8tt@world.std.com>
Subject : Re: Looking for DXCluster software

In article <CuzyoI.8tt@world.std.com>,
Daniel T Senie <dts@world.std.com> wrote:
>
>How is the PacketCluster machine to know that the UI frame with a DX
>spot just got stomped by another station starting to transmit a frame?
>Packet radio does NOT run with Collision Detection in the way that
>Ethernet does. You cannot tell, when transmitting, that your frame
>has just gotten munched.
>

It's not that difficult : most broadcast protocols work on a NAK-only
scheme - clients of the server respond only when they miss a packet,
and the server than retransmits it.
The method of detecting that missed packet varies, but a popular method
is to number the transmitted packets and complain when a hole appears in
the number sequence.

This has some difficulties for a DX-Cluster style service : as I understand
it (I don't use DX Cluster) you expect transmissions at intervals, rather
than a continuous stream. Thus, you wouldn't know you missed one until
the next arrived - a second or an hour later. Regular empty packets, sent
just to ensure everyone was up to date, might be sufficent to fix this,
and there are more sophisticated schemes around to ensure this doesn't
itself become a bandwidth hog. These require that the server keep track 
of its clients rather than doing pure broadcast, but that's no worse than 
having multiple VCs.

However, I think you're correct to be concerned about low reliability of
packet systems - on typical terrestrial packet, the success rate is very
low. As a result, a protocol optimised for the assumption that most packets
get through (and don't require ACKing) might turn out disastrously wrong -
I think a successful broadcast scheme would require both a well-engineered
high-reliability transmission scheme (good paths, no hidden terminals etc)
and a protocol that gets no worse than multiple-VCs even in poor conditions.
It might work pretty well with a full-duplex repeater and extremely well
with a polled hub (where a small amount of reverse traffic can be effectively
free by imposing no additional overhead).

I don't know how closely satellite operation approaches this (do they split
uplink and downlink packet frequencies ? ). I'd be interested to hear from 
users of the Pacsat broadcast system and even more interested to hear from 
anyone who has experimented with a terrestrial broadcast setup.

-adrian

------------------------------

End of Ham-Digital Digest V94 #285
******************************
